home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000191_news@newsmaster….columbia.edu _Fri Feb 6 10:05:54 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  8KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA27018
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 6 Feb 1998 10:05:54 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA05819
  7.     for kermit.misc@watsun; Fri, 6 Feb 1998 10:05:53 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Expect and Kermit (was: Re: frequent timeouts!)
  12. Date: 6 Feb 1998 15:05:53 GMT
  13. Organization: Columbia University
  14. Lines: 137
  15. Message-ID: <6bf8sh$5mf$1@apakabar.cc.columbia.edu>
  16. References: <6ao98e$p4h$1@apakabar.cc.columbia.edu> <ncj3ei1redz.fsf@nytrdc058.eq.gs.com> <6b5asg$ia1$1@apakabar.cc.columbia.edu> <m3oh0oclbc.fsf@idt.net>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8374
  19.  
  20. In article <m3oh0oclbc.fsf@idt.net>,
  21. Russell D. McManus <mcmanus@idt.net> wrote:
  22. : fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23. : > Also, libraries are not portable; the very library mechanism is not
  24. : > portable.
  25. : 
  26. : hmm.  of course you are right that the library mechanism is not
  27. : completely portable.  then again, neither is the 'redirect' command
  28. : that appears in c-kermit.  this fact tells me that lack of portability
  29. : is not a sufficient condition to doom an idea as far as kermit is
  30. : concerned.  the question is how 'unportable' must something be to be
  31. : rejected?
  32. : 
  33. Clearly there is more than one criterion for what gets into Kermit.
  34. I don't think it will serve any useful purpose to try to formalize the
  35. algorithm for how features are selected for adding to Kermit, because,
  36. quite simply, it isn't very formal.  But portability is always a major
  37. factor -- portability not only of command and scripting features for
  38. the end-user, but also portability (sharability) of code that we write
  39. to implement those features, so it can be shared by Kermit programs for
  40. many platforms.  How many software makers these days pay attention
  41. to any platform but Windows?
  42.  
  43. : > Increased use of Kermit overall does not pay the bills of the Kermit
  44. : > Project, so what good has been done if everybody is using "Kermit" in some
  45. : > form, but there is nobody here to answer their questions and keep up with
  46. : > their demands -- which is pretty much what we do all day (and night).
  47. : 
  48. : and this is the real reason.  funding is a necessary condition for the
  49. : kermit project to continue.  that's why i own both editions of
  50. : 'programming c-kermit' (excellent book, frank).
  51. :
  52. Thanks :-)
  53.  
  54. : a zillion non portable things must have been done for kermit-95, but the
  55. : program has commercial value.
  56. :
  57. In fact, the Kermit 95 source code is portable to Windows 95, Windows 98,
  58. Windows NT 3.51, Windows NT 4.0, and OS/2 2.0, 2.1, 3.0, and 4.0.
  59.  
  60. : ...  that is of course what drives the decision making process.
  61. : 
  62. Many things drive it.  Demand, especially from the large installed base of
  63. users who depend on us to continually adapt our software to new environments
  64. and requirements as they appear, so they can keep using the communication and
  65. automation tools they have become accustomed to.
  66.  
  67. : > The bare fact is, there *is* no "core" functionality.  No two people will
  68. : > ever agree on what constitutes the core; each one will want one more
  69. : > function added in.  So before you know it, the core is the whole thing.
  70. : > And that begs the question of the "API" -- what is the API to a program
  71. : > that has 100,000 functions?
  72. :
  73. : does kermit have 100,000 functions?  somehow i think you are exagerating.
  74. :
  75. Busted!  OK, I didn't actually count them.  Type ? at the prompt.  Then after
  76. each top level keyword, type ?.  Then after each second-level keyword, type ?.
  77. And so on, as far as it goes -- sometimes pretty far, especially in the SET
  78. command.  And most especially in K95, when you factor in the 35 terminal
  79. emulators and 43 character sets.
  80.  
  81. : ...  besides, it doesn't matter that everyone doesn't agree
  82. : what is in the core.  the kermit project gets to decide; everyone else
  83. : then becomes reality challenged if they disagree.
  84. : 
  85. What's the point?  If you don't like it, you won't purchase it, and we will
  86. have wasted all that time for nothing.  This is the 90's, the harsh decade of
  87. "every tub on its own bottom" -- whatever we do has to pay for itself.
  88. Anyway, think of all the other items that people want:
  89.  
  90.  . GUI ("100,000" dialog boxes)
  91.  . tn3270 / 5250
  92.  . Tektronix emulation
  93.  . Built-in LZW-like compression
  94.  . Security (Kerberos, SSL, SSH, SOCKS, ...)
  95.  . Chinese/Japanese/Korean
  96.  . Learned scripts
  97.  
  98. That's just handful picked at random.  Which of these should we sacrifice to
  99. produce a "library" (in quotes because this word means something different
  100. to each person) that few people will use or pay for?
  101.  
  102. Given the small number of people we can afford to pay to work on Kermit
  103. software, we have to pick our work carefully.  One of the great issues of the
  104. age is "style versus substance" -- what the software actually does versus its
  105. interface.  No interface will please everybody; we understand that and live
  106. with it.  There is a neverending demand for different kinds of interfaces --
  107. "Buzzword 1.0 compliance".  We are not equipped to deal with that -- so
  108. instead, we supply *one* interface.  It's one that we can support.  If you
  109. have a problem with it, we can get you past it.  If it has a bug, we can fix
  110. it.  We do not have the resources to support Perl, Tcl, Expect, Rexx, DCL,
  111. etc, nor the numerous APIs that are requested from us every day (Delphi, DLL,
  112. OCX, OLE, VBX, Active X, Netscape, and on and on).
  113.  
  114. : i don't think 'library' qualifies as a 'Buzzword', and if it does,
  115. : then it would certainly have a higher rev than 1.0.  the biggest
  116. : platforms support the library concept: all flavors of unix, win95,
  117. : win-nt, os2, and surely others that i am not personally familiar with.
  118. : 
  119. But what is the interface to the library?  Come sit in our chairs for a while
  120. and listen to the conflicting demands.  Company A wants "just the protocol"
  121. because they already handle the communications functions themselves, whereas
  122. Company B wants the communications and they're not interested in the protocol.
  123. Meanwhile, Company C wants the VT320 terminal emulator (but not the Wyse or
  124. Data General), whereas Company D wants the character-set support and could not
  125. care less about the other stuff.  Then Company E comes along and wants --
  126. would you believe -- the command parser.
  127.  
  128. Meanwhile, to which "standard" must the library "conform" -- Delphi, DLL, OCX,
  129. OLE, VBX, Active X, Netscape -- 1.0, 2.0, 3.0, 4.0, ... -- these all have
  130. different structures, different conventions, different requirements.
  131.  
  132. : i'm still confused about one thing: why is it impossible for the
  133. : kermit project to make design decisions about what should go in a
  134. : library?
  135. : ...
  136. : how about the same amount as the current version of kermit; pay
  137. : for a copy of the book if you want support?
  138. : 
  139. The amount of work that would have to into a "library" that would satisfy
  140. even 10% of the people who are asking for such a thing is staggering, and
  141. there are no indications that anybody would pay the kind of money it would
  142. take to cover the development costs.
  143.  
  144. : and there is something to be gained: a quick tour through the
  145. : quotation rules in the kermit language demonstrates how difficult it
  146. : is to have a single syntax that is useful for both interaction and
  147. : programming.
  148. :
  149. Only when you need to refer to DOS pathnames :-)
  150.  
  151. : ... one encounters similar problems when programming in a unix shell
  152. : language.  don't fault me for dreaming of something better!
  153. : 
  154. Of course not.  But who will do the work, and who will pay them to do it?
  155.  
  156. - Frank